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(54) TiUe: PARTIALLY REPLICATED DISTRIBUTED DATABASE WITH MULTIPLE LEVELS OF REMOTE CLIENTS 
(57) Abstract 

A method of and system for collecting, storing, and retrieving data in a database management system. The database management 
system^lncludes a master database server (4). at least one workgroup server (315). and a plurality of workgroup user clients (310). The 
workgroup server (315) is interposed between the master database server (4) and said workgroup user clients (310). The method creating a 
transaction in a local database resident oh one of the wcn-kgroiip user clients (310), entering the transaction into a transaction log resident on 
the workgroup user client (310). and creating a transaction file corresponding to the transaction in an outbox of said workgroup user client 
(310). Next, the transaction file is copied to an inboxr identified to the workgroup user client (310) and updating the transaction file into a 
workgroup database (305) resident on the workgroup server (315). TTic workgroup database (305) includes a transaction log. Finally, the 
workgroup database (305) is read into the transaction log, skipping those transactions which originate at the master database server (4). and 
creating data files corresponding to the agency workgroup database. Data files corresponding to transactions originating at the workgroup 
user client (310) are copied to an inbox on the master database server (4). This inbox concsponds to the workgroup server (315). The 
transactions are copied into a master database (3) oil the master database server (4). 
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PARTIALLY REPLICATED DISTRIBUTED DATABASE 
WITH MULTIPLE LEVELS OF REMOTE CUENTS 



INTRODUCTION 

L T^hnicail Field 

This invention relates to a system and method for providing updates to a network of 
' 10 partially replicated relational database' systems', ^d; mbre paiticulairly , for providing 
' ^ ' an efHcient' means for cbmpiitihg the visibility to a client on the network of a 

^ ' ' ' 'transacfibh' processed ' ' 

n. Background 

15 Relational databases are a commonly-employed data structure for representing 

■ - data in 2i 'business or other environment. 'A relational database represents data in the 

' ''-^ ■ ' form of a 'collectioh of two-dimensional tables, ^ch table cbmjprises a series of cells 
' arranged in rows arid coluniris. Typically, a row' in a table represents a particular 

• ' - observation. A column represent either a data field or a pointer to a row in another 

20 --table.- - ^ "■^■•"■'^^^ ^ -l* ; -rrrv-- 

' For example^ a database describing ^a^ structure may have one 

^ table to describe each position in 'the organization, another table to describe each 

Employee in the organization"^. TTieiemplbyee table may include' information specific 
r 25 ' to the empoyee, such as name/'emp^^ numl^r, age, sil2tiy, 6tc. The position 
'"^ table may iiiclude iiifbnhatioh specific tb th^^ such as the position title 

("salesman", "vice president",' etc.)^ a salary range, and the like. The tables may be 
related by, for example, providing in each row of the employee table a pointer to a 
particular row in the positibri table, coordinated so that, for each row in the employee 
30 table, there is a pointer to' the particular row in the position table that describes that 
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replicated database is not made to the central database, leading to a discrepancy 
between the information that is stored in the replicated copy of the database and the 
information that is stored in the central database. Although it is possible to journal 
modifications made to the iiq)Ucated copy and apply an identical modification to the 
5 central database, one problem that this approach faces is the possibility of colliding 
updates; that is, where a user of a replicated copy makes a change to data that is also 

changed by a user of the central copy or by the user of another replicated copy. 

. . • • . -.w . ■: i • .... 

It is therefore desirable to provide a capability to maintain one or more 
* ' 10 partially-r^licated copies of a central database, in such a way that the degree of 
' replicationi may be easUy chiahged without requiring a refresh of the entire rq)licated 

''^^ database, iand that perihitk updates to be^ coordinated among users of the central 

' ' database and users bf the'paitially replicated databases. 

15 Sim«\^ OF THE INVENTION 

' The present indention is directed' to a ni^hod of maintaining a partially 

'. ;v rcplicated database in su^ch'^^a way that uj^ to a central database, or to 

* another partially replicated oatabase, are selectively propagated to the partially 

replicated database. Updates are' propagatdi to a partially replicated database if the 
20 • owner bf the partially rqpUcatwl database is deerhed to have visibility to the data 
being updated. Visibility iV determine By u^e bif predeteim rules stored in a 
'--"■'^^ riiles database! In ohe^ ^ecVof 'the invention/ the stored rules are assessed against 
data content of vafious t^l)les that make iip a logical entity, iknown as a docking 



25 



' 30- - 



object, that is being updated. 



In another aspect of the invention, the stored rules are assessed against data 
content of biie or inore dbcldng objects' that iare iibt neobssarily updated, but that are 
related to a docking object being updated. In one embodiment, tHe visibility attributes 
of the related docking objects are^ determined. 

' ' In yet another aspect of the invention, chwges in visibility are determined to 
enable the central cbiiiputer to direct the nodes to insert the docking object into its 
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workgroup connected clients (330-a). In this embodiment of the invention the 
workgroup server (315) is directly connected to the workgroup connected clients 
(330-a). The method of this embodiment of our invention includes creating a 
transaction in a local database resident on one of the workgroup connected clients 
5 (330-a), entering the transaction into a transaction log resident on the woikgrbup 
connected client (330-a), and creating a tranisaction file corresponding to the 
transaction in an outbox of the workgroup connected client (330-a). In this 
enibodimeht of bur invention, the next sti^p is copying the transaction file to an inbox 
identified to the workgroup connected clleiit i(33b-a) and updating the transaction file 
' ' 10 into a woricgroiip database (305) resident on ithe workgroup server (315), where the 
workgroup database (305) includes a transaction log. The transactions are directly 
' ' ' eritereii into the transaction log in the workgroup server (315)» 

'^^ A still further embodiment of our invention is its incorporation into an article 
^ " of manufacture, that i^, a disk, a tape, or the like. TTie article is a computer usable, 
15 i.ei, readabte, medium having computer readable program code for collecting, 
storing, arid retrieving data' in a database mahagemeht system. The database 
management is one, as described above, having a master database server (4), an 
application ^iseivef (303), at leist one wdikgniV seivW* (31 and a plurality of 
' wbrkgroiip^iisei- ciiehts^^(3l6), where th^^^ server (315) is interposed 

20 between the master da;tabase The 
• computer readable* pn>gram in the ahicle of miiufacttire incluides com^^^ readable 

prbgrarii code for caus computer to create a trMsactioh in a local database 
^' resident bii 'one of more b^^ 

' the transaction into a transiactioh log resident on ont of the workgroup user clients 

25 (310), that is; the^wbrkgroup user client (3f6) where the transaction originated, and 
^ * creating a^tiah^ction' file cortespbhding^^td th^^ in an outbox of the 

* ' * ^ workgroup user '^client '^^^^^ In this embodiment of om invention the computer 
'"^ • readable projgrain code causing' the coihi^uter to eff^^^ transaction file to 

an inbox identified to the workgroup user client (3 10) and updating the transaction file 
30 into a workgroup database (305) resident on the workgroup server (315). The 
woikgrbup d^iuibs^e (305)' iiicliideis a transkbtibn 16g; Finally, the computer readable 
■"^ ' program' cckle^ c^ses the^compiiter to effect rea^g the workgroup database (305) 
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present invention. 

Figure 2 depicts a database schema tiiat shows the relationship of the various 
components that make up a Dockiiig Object. 

Figure 3 depicts steps performed by an update manager to update a database. 

Figure 4 depicts stqps p^rfbnhed by a Docking Manager to transmit and/or 

receive one or more traii^ction logs. 

.. J' • • * ... 

Figure 5 depicts tfie^ §teps performed by a hierge processor to meige 
transaction log records ihto iaii ejdstm^^ ^ 



Figure 6 depicts the steps performed by a log manager to prepare a partial 
15 " transaction log: - ^ ^? > :t. ^ ly. ^ 

Figure 7 depicts the steps perform^ by a visibility calculaioil' for calculating 
r , ^ . visibility for a dbcloiig ob^ invoked by a^log manager. 

20 Figure 8 dqpidts Uib' st^ partially rqilicated 

databiase in response to a'chaMge in dak visibility!: ' ' ■ ' ' 

Figure 9 depicts the logical database configured to support multi-user docking 
' - ' clients.' ^-'^^ ^^-^ • ^^^-"^^ ' - - 

Fi^relO depictsl^dats^ 
multi-user tfocking- cHM/'*^^^ ^ ' ^ ^ 

30 Overview i^''^'*';^*' ^^^'^ 7'^''^- br.^t'-^ ^o^fT-^M^ ^..^ ■^■■n m^. • 

Figure 1 depicts iii^^ovemew^^ embodiment of tiie 

present invention. Figure 1 dq>icts a central computer system 1 and three remote 

-7- 



ly 



BNSOOCia <WO_S838564A2_L> 



wo 98/38564 



PCT/US98/03752 



At some point in time, at the convenience of the operator of central computer 
system 1, log manager 9 is activated. Log manager 9 takes as input central update 
log IS and produces as output a set of partial logs IV-a, 17-b and 17-c according to 
visibility rules as will be further described herein. Each of partial logs 17-a, 17-b 
5 and 17-c corresponds to one of nodes 21 -a, 21-b and 21-c. When a node docking 
manager such as node docking manager 2S-a enters into communication with central 
docking manager 5 and optionally requests transmission of its corresponding partial 
log, centtal docking manager 5 takes as input the appropriate partial log, such as 
partial log i7-a, and presents it to node docking manager 2S-a. Node docking 
10 manager 25-a then rq)licates partial log 17-a as merge log 37-a. 

At some point in the future, at the convenience of the operator of node 21 -a, 
merge processor 27-a is activated. Merge processor 27-a takes as input merge log 

37-a, audi applies the updates described therein to partially replicated database 23-a. 

= -15 • ■ " ' " ' ' 

In addition to node 2i-a, Figure 1 also dq>icts two additional nodes 21-b and 
21-c. Node 21-b is depicted in communication with central computer 1. However, 
unlike node 21 -a, the operator of node 21-b has requested only to send his updates 
to central computer system 1, and has not requested to be presented with changes 
20 made elsewhere to be made to his partially replicated database 23-b. This may be, 

for example, if the operator has an urgent update that must be made as soon as 

\y.k\- . n:.;C'. ^ ■ ■ -V ' -'*:•^*.t: - 

possible, but does not have the time to receive updates from other nodes. 

Accordingly, Figure 1 shows only transmission of node update log 3S-a from node 

docking manager 2S-b to central docking manager 5, and no transmission from central 

25 docking manager S to node docking manager 25-b. Accordingly, the merge manager 



for node 21-b is not activated and is not shown. 



Likewise, node 2r-c is dq)icted as not in communication with central 
computer system 1 * Accordingly, the docking manager for node 21-c is not activated 



30 and is not shown. 



By the cycle descifibed above, updates made by each of nodes 21-a, 21-b and 
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of a Docking Object is "visible" to a particular node 21. If a Docking Object is 
visible to a particular node, that node will receive updates for data in the Docking . 
Object. Visibility'RuIes arc of two types, dqjending on the field RULE_TYPE. A 
Visibility Rule with a RULE_TYPE of "R" is referred to as an SQL Rule. An SQL 

S ' Rule includes a sbt of Stiiictured Query Language (SQL) statements that is evaluated 
to'd^ermihe if any datk 'meeting the criti^ria specified in the SQL statements exists 
in the Docking Object. If so, the Docking Object is visible to the node. A Visibility 
Rule with a RULE^TYPE of "O" is referred to as a Docking Object Rule. A 
Dd^king Object Riile spebifies ihbther I^bckirtg Object to be queried for visibility. 
10 If the^^piecified Dockih| Olyect i^ visible, them the DckScing Object pointing to it is 

• ' also visible.' ' * 

' ^ A Related Docking' Object is a Dbckihg Object that is propagated or deleted 

^ ' when the Docking t)t)ject!uhdercori^idera^ ts'propagated bir deleted. For example, 

15 an ORkntunity Docking Object fMy Efocking Otyects representing the 
sales contacts, the organizations, the products to be sold, and the activities needed to 

■ • pureti^ the^bppbrturiity Opporhinify Docking Objiect is propagated from 

: Central likabasS^^ to 6ne4# nodie databaseis'23^ IBe re^ iiocking objects are also 

-^K'-' ^ -prepaiat^^"^^ J-^/-^...e5l MlJ^: . ^ r- ^ 

- ^ Figiii^'i'depiicts i^a^ 
■ ' components thk mlicyupa O 

- it doei^ n6f^deiU:ribe the iii the datat^^^ the schema is 

a separate database that defmes the structure of the database being accessed. That is, 
r^nhl 25 -it is a^database cbinpnsing EbleslHa^^^ the relationships and data contexts of 

^'^•'5^ ^ '--^andtHef dalabas^. ^W^-; ur. :i :^ -m-^ ... .. ^r- 

:^ ' Eafch of the '^blk Sliown' m^^^^^^^ iri^i relational database, and 

rla . as such is in^rdw^olumhtb^ l^y ooiufiins^i^ common to 

A 1 aD the mustnited tables. '^Mh'fi^^^ 

^^ ^^ '30 particular row ih'the tabled' as' -well as fields to'iack the daiaand time that a row was 
0 r . ^ cireated and last ^modified; and the identity of iihe user who dreated or modified the 
row. InHadditidn, efcK*^ta^^^ fields' specific to that table, and which arc 
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Table S_DOBJ_VIS_RULE 71 contains the visibUity rules associated with a 
particular Docking Object. S_DOBJ_VIS_RULE 71 contains the fields DOBJ^ID, 
RU1£_SEQUENCE, RULE^TYPE. SQL__STATEMENT and CHECK^DOBJ^ID. 
Field DOBJ_ID identifies the Docking Object with which a particular visibility rule 
5 is associated. Field RULE^SEQUENCE is a sequence number that indicates the 
sequence, relative to other visibility rules in table S_DOBJ_VIS_RULE 71, in which 
the particular visibility mie should be run. RULEJTYPE ispecifies whether the 
' particular visibility rule h 6f type "R," indicating iah SQL visibility rule or of type 
v i tf , . "0/ indicaidng a Dockmg Object visibiKty m^^^^^^ 

'^^ 10 • - • ■ . ^ • ' ■ • • 

If RUI^^IYPE is equal to "R, " field CHte 
c:i . arid field SQL^STATEMENT contains an SQL statemeiil that is evaluated using the 
I .1- Primary ROW^n) of the piiinary table associated with this Inking Object and a 
particular Node 21 . If the SQL' statement retiinisi suiy records,' t^^ Docking Object 
IS is deemed to be visible to the Node 21 for which visibility is being determined. 

■:f:. V. :^^;.n.i^t^.i : If RUUETYPE is equal to "O;" bbt^'lfiyd'^fcHECKll^ and field 
; . - V ' -SQLj^sTATEMENT are meaningful. Field diffidc^Dbm_ro V^^^^ a docking 
^ r;r - object whose visibility should be determined. If the specified docking object is 

20' deemed to be visible, then thb docking objec^^ 
? " !y. [ visible. Field SQL_^STATEMENT contains a SOt stotemCT^ executed, 
• . i ' returns the Row-ID of the docking object 'identifieid by CHECK_DOBJ_ID that 
.nr;, : corresponds to the docking object instance associated with the visibility rule. 
Table S^APP^TBL 73 is an Apjplicatioh table that describes 
25 in a particular application. It is pointed to by tabte S^DOBJ_TBL 69 for each 
member table in a docking object, and by table S DOBI for the primary table in a 
> V docking object. S_APP_TBL 73 points to table S^APP^COL 75. which is an 
>,ib:r . .. io. Application Column' Table that describes the columns of data in a particular 
i.;^ : -^^lication. S_APP_TBL 73 points to table S^APP^COL 75 direcUy through a 
■ ' 30 primary key and indirectly tirough such means ^a^ 

VsGT Key Colunm Table 83, and Column Group Table 85. Ilie 'relationship of an 
Application Table, Application Column Table, Foreign Kiey Column Table, User Key 

-13- 
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An update manager 1 1 executing in central computer system 1 operates in an 
analogous manner, except that it updates central database 3 and writes its log records 
to central update log 11. 

5 Docking Processing 

Figure 4 depicts steps performed by a'£k)cking Manager 25 such as Docking 
Manager 25-a, 25-b or 25-c to tnuismit and/or receive one or more transaction logs. 
D>ocking Manager 25 is invoked by the user of a remote node ^uch as node 21 -a, 21 -b 
or 21-c, wriefeby the u^er requests that the node dock with central computer 1 to 
10 upload an Ujadate log such as update log 35-a to central computer 1, to download a 
partial log such as partiai log i7-a, or both. Execution of Docking Manager 25 
begins in step ^2l:'Jn st^f23, Docld^g Manager 25 connects with central computer 
1 under the control of Central Docking Manajger 5. This connection can be any 
connection that enables data exchange. It is anticipated that the most common form 
15 ' of a connection is a tetepfo used in conjunction with a n^odem, but other forms 
of data cbnhection, such' as a Local Area Network or a TCP/IP connection may also 
bt used. Step 125 i:hecks to see whether the user Has i^uested that node update log 
35% be upioiaded'tiy^ii^ Computer 1. Ifso^ ewjcution p!^^ to step 127. 

If riot, step 127 is skipped 'and confel is given to step' 129. In stqp 127, Docking 
20 Manager 25 'upioacls its update \6g to ceiitrai computer 1. The upload may be 
acdompiished with itoy loiown fUe^t^ such as XMODEM, ZMODEM, 

^ KERMITrlTW'^Cn'l^ aiiy other m^ of transmitting data. In stqj 

129, Dbcicihg Mki^Liger 25 checii^ to see whether the iiser has requested that a partial 
' log such as* pakiallog i7^a' b6*cl6wnload«l froni^icentral Computer 1 . If so, execution 
25 proceeds 'to 'step 13i . • if nbt, ^ep 131 is^'Mpped and control is'given to step 133. 
In step 131, Docking Manager 25 downloads its partial log from central computer 
i . The dbwriioaB may be'aa^mplisHed with any known ffle transfer means, such as 
XMODmi, ZSlQi^ ITpT^ASCJI trans^^^^^^ other method of 

* transmitting data! Itf'sltqp 1^3,' data mmsfer, Docking 
30 ■ Manager "25 exited -'^^ 

Merge Proce^inV - ^^^-^ '-^ ' - 

Merge processing is pierfonned by a processor such as node merge processor 
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In the above example, when the transaction for node 27-b was presented to merge 
processor 7, merge processor 7 would compare "Keith Palmer," the prior value of 
the field as recorded by h(jde 27-b to "Carl take," the present value of the field as 
recorded in central database 3. Detecting the mismatch, merge processor 7 may then 
5 generate a trsmsaction to chanjge the valiie "Greg kmerson" to "Carl Lake," and write 
that transaction to updatb log 15. ' In a si^bseqiient docidng operation, that transaction 
' - would be routed back to node 27-b to bring Its database 23-b in synch with the other 

• ^databaseSr " ' ' ' ''''' 

* ' The* above '^is one example of a: CO resulting corrective action. 
>: >^>v; iQ Other types of collisioris^includerfcr a row that has previously 
' • been deleted, insierting a row^ft^^ Merge 

' prcteessing must detect aiid rarrect eabh of the^^ This may be performed 

using kriy of a number of well-known methi^ is not discussed ftirther 
Figure 5 depicts the ste^ 
1./ : 15 -- processor 7. Although it cii^icts'merge^^p 

to transaction log 15, it is equally representative of a node merge processor such as 
':^npn\ I c riode merge processor 27^^7-b 27-t up^ing^^ 23-b or 23- 

c. Meige pr^ ¥ri^s?qp 143, nierge processor 7 fmds the 

' ^ first unprocessed transaction on received log * 1^. ' In step 147, merge processor 7 

• 20 ' selects a transaction from receivecilojgl^ 

to update database 3 according to the transaction selected ih step 147. In step 151, 
'i mierge pircessor 7 detem database upclate of step 149 failed due to 

r y > . . ;a'collision. - if so', mclrge prb'c^sor proceeds^to stq) 153, which generates a corrective 
' ' ^ tiahsaction. "'^ FbU6wii^^ the corrective transaction, the merge 

25 processor' reitiums to St atteinp^ to update database 3. If no collision 

was detected in step 151, execution proceeds -to* step ~1 57. in'^^ep 157, merge 
. . ;;i i >\r:- prbce^ing checks to see'if it i^ execiitirig^ 1. If so, step 155 is 

V ; . / i: r I Executed to' jouVriar W^t^ In' aihy case, either if stq) 157 

* : ^Hi * ' '^determiiies that thfe merge pixicessing is being perfomed on a nod^ or after step 155, 
^- ' 30 ' ^ execution pr66eeds to step' l!59i Stqi 159 c^eClcs' to see i^any transactions remain to 
^ ' ' ' be processed' from log 19.*' If so;'exeicutidh il^>^ from' stq) 147, where the next 
^ * - ' transaction is selected. If riot, merge processing exits in step 161. 
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data stored in the schema depicted in Figure 2, to determine whether a particular 
transaction that updates a particular row of a particular docking object is visible to 
a particular node. 

The Visibility calculator begins execution at step 201. In step 203, the 

visibility calculator makes a default fmding that the transaction is not visible. 

Therefore, unless the visibility calculator determines that a transaction is visible, it 

* will (exit with a finding \)f no visibility. In step 205, the visibility calculator selects 

the first visibility riile associated with the docking object. This is done by finding the 

table S_DOBJ_VIS_RULE 71 associated with the current Docking Object as pointed 

10 to by table S_DOBJ 61 . In step 205, the visibility calculator selects the row of table 

-S_DOBJ_VIS_RULE 71 with the lowest value for field RULE_SEOtJENCE. 

. ; In step 207^ the Visibility Calculator checks the field RULEJTYPE for a value 

^ ^ of "R." The Value of "R" indicates that the rule is a SQL visibility nile. If so, the 

^ Visibility Calculator ^proceeds to step 209: In step 209 the Visibility Calculator 

15 obtains a SQL^statemeiit from field SQL_STATEMENT aind execute it. An example 

of such an SQL statement might be: • * - ^ ^ ' 

SELECT FROM S^OPTY_EMP ^ 
WHERE OFI^ :PrimaryRpwId 

, This S^L,^ stateme^^ a query to be, made of .application table 

. .S OPTY EMP. r The Query selects any records meeting two criteria. First, the 

.records selected must have a field pPTY ID, which is a row jd or key, equal to the 

.Primary Row-ID of the -Docking Object whose ^visibility is..being determined. 

25 Second, the records selected must have a field EMP ID. which may be for example, 

an identifier of a particular employee, equal to the NpdeId,of the.^node for whom 

visibility is being determined. . In ordinary language, this SQL statement will return 

records only, if a row is found in a table that matches employees to opportunities, 

where the opportunity is equal to the one being updated, and the^ employee to whom 

30 the opportunity is assigned is the operator of the node. 

This is a sLmpUsti^^^^ provide^ for maxim cpmprehrasion. More 

complex SQL statements are possible. , For example, the rule: 

SELECT 'X' FROM 
' &Table_Owner.S_ACCT_POSTN ap 
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Step 243, the Visibility Calculator references the visibility just calculated for a 
docking object. If the Docking Object is visible, execution proceeds to step 245. 
Step 245 references the S_DOBJ_INST table, to verify that a row exists for the 
Docking Object for the ciiitent node. If a row exists, this indicates that the node in 
5 question already has a copy of the referenced Docking Object, and the routine 
proceeds to step 255, where it exits. If,' however, no row exists for the Docking 
Object at the node being ^processes, ibis indicates that the node in question does not 
have a copy of the-^Dockinig Object on its partially replicated database. The routine 
then proceeds to step 247,''Where a transaction is generated tb direct the node to inseit 

10 the Docking Object into Iti jpafidally replicaf^ 'Qambase. 

If step 243 ' determines that the Docking Object is not visible, execution 
profceeds to step 249. Step 249 references tfie S^DOBJ^INST tablie, to verify that no 
row exists' for the Docking Object ifor the'current nbde. If step 243 determines that 
no row exists in the S^DOBJ^INST ybie for^tlie current docking object for the 

15 current row, this indicates that the node' iri 'question does not have a copy of the 
referenced Ddckiiig Object, and the routine pr^eeds to step 255, where it exits. If, 
however} a n)w exists^ for the D6cking'^C)hij^i a? the node tiding processed, this 
indicates that the node in question doW^have 'a copy *'of t^^ Object on its 

partially replicated database. The^foutine^Wen probebd^^^^ step 251, where a 
-20 transaction is generated^ to' direct the hdcle'^tb delete the Docking Object from its 
-piartially itpUcated database.' ' ^ nici'ii /v.:u k / } 

Referring again to Figure 7, following the^data synchronization routine of step 
228, the Visibility Calculator proceeds iO|Stepj-229i where it exits. Referring to 
Figure 6, as previously described, the resulting finding of visibility is available to be 

25 checked by the log manager in step 183 to determine to write the transaction. 

Referring again to figure 7, if step 211 determines that no records were 
returned by the execution of the SQL statenient in step 209, execution proceeds with 
step 215. Step 215 checks to see whether there are any remaining visibility rules to 
be assessed. If not, the visibility calculator proceeds to stq? 228 to synchronize the 

30 database, and then to stqp 229, where it exits. In this case, the default mark of no 
' visibility that was set in step 203 remains set. This value wili also be used by the log 
maiiager as shown in Figure 6, step 183, to determine not to write the transaction. 
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Calculator recursively invokes itself to determine visibility of the related docking 
object. The recursively invoked Visibility Calculator operates in the same manner 
as the Visibility Calculator as called from the Log Manager 9, including the capability 
to fiirther recursively invoke itself. When the recursive call concludes, it returns a 
5 visibility indicator for the related Docking Object, and control proceeds to step 227. 
In step 227," the Visibility calculator determines whethbr the related Docking Object 
was determined to have been visible. If so, tHe Visibility Calculator proceeds to step 
213 to mark the originally current Docking Object as visible, and then to step 228 to 
synchronize the databiase and then to step' 229 to exit. If the related Docking Object 

10 was not determinied to be Visible, control proceeds to step 215 to determine whether 
additional visibility rules remaiii to bb assessed! 

The Visibility Gdcuiatdr- in conjunction with the Log Manager is therefore 
able to determine what subset of update tiSisactidfa data is required to be routed to 
any particular node. This operation serves to reduce the transmission of unneeded 

15 data from the Central Computer 1 to the various nodes siich as nodes 21-a, 21-b and 
21-c that utilize partially replicated databases, and to recluce tte system resources 
such as disk space needed to store, and the CPU tinie needed to process, what would 
otherwise be required to rhaiiitain a fully replicated datkbasd on each remote node. 
This operation' of the log mahager '9 in conjunction ' with the Visibility 

20 Calculator herein described will be apparentfrbm reference to ^th^^^ and to 

the drawings. However;^ as ia further aid iii tlie'clbscriptidn of these facilities, a 
pseudocode represientatidn of these facilities' is' hereto attached as aufi 'Appendix. 
' Multiole^User Ddckihg'Gliei^^^^ 

The present iiiventidfl TOay be enhM^ adding suppoit for multi-user 

25 docking'cliehts.^This capability extends the docking architectiire to pennit replication 
of database' ihforinatibh from 'the' master database seiver tb a variety cif geographically 
dispersed wdHcgroup^'se servers). This capability 

^ ^allows multiple usenlto coimect to these agcmi^^'da^base servere users need 

'to synchronize 'theif lociU database^ ag^ the master database se^^ 

30 Multi-user dd&king clients provide Uie basis 6f a single^ Integrated, logical 

database. Figure 9 depicts the logical database configured to kurort multi-user 
docking clients. A single master database 3 at h^qu^rs routes transactions to 

^ -23-. 
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(315), where the workgroup database (305) includes a transaction log. The 
transactions are directly entered into the transaction log in the workgroup server 
(315). 

Multi-user dockiiig clients comprise an agency server (315) (or simply, 
5 "agency"), running a workgroup database 305, and one or more workgroup users 
(310) connected to the server via a LAN or other connection. Agency server (315) 
may be a WiiiSbWs/NT server or other server. Multi-user docking clients behave in 
' the same way as single-user mobile clients. In addition, multi-user docking clients 
store data for one br many users; allow multiple users to access and change data on 
10 the workgroup database simuitaiieousiy ; permit users to execute server-side programs 
against the workgroup; and execute a periodic dockinjg program to exchange data with 
the master databaise at predefined times or ihteivals* 

in this aspect of the ihvehtioh,' the database is configured to support a plurality 
of users in a single dockiiig entity. More particularly, one aispect of the invention is 
15 a method of collecting, storing, and retrieving data in a data base management system 
havmg a master database server (4), at idast one wbikg^ server (315), and a 
plurality of workgroup user clients'(310^/' lii' this embbdiriient W the invention the 
workgroup iservef (315)'is inteiposed betwi^^ the master database server (4) and said 
workgroup user cliehts^(3i0). The' meffi'b^ embodiment of our invention 

) includes treating a tii^ workgroup 
user cUehts (3 10)f entering the transaction into a t^^ resident on the 

workgroup user clienr^^^ creating a tramsaction file cbmespondmg to the 

transactioh in iui outbox^bf the workgroup user ^^^^^^^ 10). lii" tf^ embodiment of 
'oiir invention; the next siep is copying the triisaction^ an inbbx identified to the 
) wbricgnAip user client ([310) and ^ u a workgroup 

datab2u;e (30S)*Vesideht oh%e Wrkgi^^ (315),' where tibe workgroup database 

- (305y ihcludes a transactidA^log. the step'in'the mt^bd of our 'invention includes 
reading the workgroup database (305) transaction log , skipping those transactions 
which originate at the insSter databasb server(4) sbis^ to avoid looping, and creating 
) ' data files corresponding to tKe entries in the ii^saction log. Ilii^ entries are copied 
to ah inb6x on the 'master database s6fver 1[4) 'which corresponds to entries on the 
' workgn*ip seifver these entries are u^ tb i^^date tfeeltransactions into a 
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(303). at least one workgroup server (315), and a plurality of workgroup user clients 
(310), where the £^pUcation server (303) and the woikgroup server (315) are. 
interposed between the master database server (4) and said workgroup user clients 
(310). In this embodiment the code causes the database management system resident 
5 on a workgroup client to create a transaction iii a local database resident on the 
workgroup user clients (310), enter the transaction into a transaction log resident on 
the workgroup liser client (310) j and create a tiarisactiori file corresponding thereto 
in an biitbox of saiid workgrbup user client (310). Next, the iianskckon file is caused 
to be copied to ah ihbbx identified to the^ workgroup user client (310) and the 
- ' 10 transactibh file is updated into a workgroujp database (305) resident oh the woricgroup 
> server(3 15): To be noted is that the workgroup database (305) includes a transaction 

log. Next, the software reads the workgioiip database (305) tranisaction log, skipping 
' * ' ^ those transactions which originated kt the ni^teif database server (4), that is, to avoid 
loopijig, cre^g data files corresponding to the entries ih' the transaction log, and 
15 copying data files cbirespbnidihg to transactions bnginating at the workgroup user 
r;i.; ' client (310) to an iribox ' on t^^^ database server (4) corresiwnding to the 

n\ >:f- < workgroiflj iseiver' (315), iand updating tlie transactiotis into k masler ^database (3) on 
the master database server (4). 

- 20 The following flow descriptions descri^^ 

n i; .! . ; Md cbiTCsixmdericePi^^ . .; vr ;j; >r: 

> o J . In offler'to process a tnuisac^ 

headquarters *6de;' t^^^ ffie traiisaction the agency 

i database and creates a dx file iii^ the ajgOTcy n^e's oiitbox.' Tlife periodic docker 

^' - 25 checks the t)rigihaling node 
3n .0 skips those'whichonginate at t^^ 

. V. - node, in cdhfigiirations' having niultiple agehcy levels/ This i^^^^ because the 

• ^ ^ ^ ^ periodic docker^dims.on^ti^ merge the 

changes from the HQ node. Transaction logging is needed for the%g manager to 
^ .. 30 route those transactions that must Be' ibuteS^^fo clieht^nddes down below, but not 
K routed back ttf'the Beadquaiters node.' Hie 

^ - ' periodic docker ujidates the 'dock^^ r^uiired 'so that the log 
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with the workgroup server (315). A single mobile user (21 -a) can access a single- 
user database (23-a). 

In order to process a transaction from an agency to a client, the log manager 
executing on the agency reads the transaction from the transaction log, checks 
5 whether that transaction is visible to the mobile client. If so, the log manager writes 
the corresponding dx files into the client node=s outbox on the agency node. 
Subsequently, the client node docks with agency node. The dockbg manager reads 
the dx files from its outbox and copies them down to the inbox on the client node. 
The docking meager then calls datamerge to merge these transaction records into the 
10 client database. No transaction is Ibggfed. - * 

Figure 10 depicts a database diagra describing the database d^^^ to support 
multi-user docking clients. » Node table 65 (named S-N6bE)%as'a one-to-many 
relationship to' node relatipiislrip't^^ (named S_NODR/REL), node employees 
table 365 (named S^NODE^EMP); ' dock object instance table 370 (named 
15 S DOCK INST, equivalent Jo S bOBJ INST .table 63) and dock status table 375. 
Node employees table 365 has a many-to-one relatidnstiip wi& ennpl^^ table 380 
(named SJEMPLOYEI^., v i/ 

Node employees table 365 serves as an intersection table between nbde table 

65 and employees table 380. It includes the following fields. 

20 Column Tvpe Constraints 

ROWJD , .yARp[AR2(15^^^^ Piimai^r^,^^ 

CREATED DATTETIME ' nofnuU 

CREATED^BY VARCHAR2(15) not null 

LAST_UPD DATETIME . , not null 

25 LAST^UPD^BY yAR!pHAip(15^^ not^nuU ' ' 

MODinCATION_NUM NUMBER " " not'nuU 

CONFUCT ID VARCaiAR2(15) not nuU 

NODE ID . , VAR(aiAR2(15) Uniquei 

EMPTO ---^ '^-^ - ifARC^mS) ' 

• -t " ref(Emp) 

'f:f7;.7iv 'o^? .n:^:- , not null 

Node employees table 365 is indexed as follows: 

unique index S_N0DE_EMP_P1 on S_NODE_EMP (ROW_ID) 
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LAST_UPD_BY VARCHAB2(15) not nuU 

MODinCATION_NUM NUMBER not null 

CONFLICT_ID VARCHAR2(I5) not nuU 

NODE_ID VARCHAR2(15) not nuU 

5 SUB_NODE_ID VARCHAR2(15) not null 

RELATION_TYPE VARCHAR2(30) not nuU 

Node relationship table 360 is indexed as follows: 

unique index S_N0DE_REL_P1 on S_NODE_REL (ROW ID) 
10 • • • . ;■ ' •■r.a-.'i.-;. . 

unique index S_NODE_KEL Ul on S NODE.REL 
^ . - r (NODE_iP.Sim_NODE_ID,KEI:ATION_TYPE,CONFUCT_ID) 



15 



non-unique index S_NODE_REL_F2 on S jNODE__REL (SUB^NODE^ID) 

CONCLUSION ^ , 

Various modifications to these embodiments will be readUy apparent to those 
skilled in the art, and the generic principles defined hierein^^m applied to other 
embodiments without the use of inventive faciirty. Thus, the pi^aent invention is not 
20 intended to be limited to the embodiments shown herein, but is to be accorded the 
widest iscdpe consistent with the principles and novel features .d^^^ herein. 

All -publications aind patent applications mehtioned ' iri Ithis ^Specification are 
herein incorporated by reference to the same- extent as if eacli individual publication 
or patent application was specifically and individually indicated to be incorporated by 
25 reference. 

The irivention now being fiilly described, it will be appai^^ of ordinary 

skill in the art that many changes and modifications can be ' ma^^ 
departing therefrom. *T.'r . . r -^iC 
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Goto next transaction 
END IF; 

Process all other types of transactions 

5 

-- This is the visibility calculator! 

This routine also processes implicit visibility events 
Later: Data Merge can call this function to check 
whether a txn is 
10 , still visible when merging txns into a laptop or 

' >s4ryef database. 

CheckVisibility (LaptopNodeld, LogRecordType, TableName, 
TransRpwId) . , _ . 
IF txn is visibie THEN 
15 Write transactions to UserTxnLog file depending on 

the 

■■ type 'of LogRecordTypia . 
Write the:^. txn to the user log file 
' ++NumBatchT3chs 
20 END IF; 

- - Finished processing the txn 

Commit '^ (i:f ' rieede^) ' \' 
IF NumBatchTxns = M^xBatchlbms THJ^ 
25 Assume that separate, -process comes around and 

' "diifetes ' ■ ' " ■ " 

Txns^ in ^ S_DOCK_TRANSACTION_LOG that have been 
prociessed '-'■'•^'^ ^ .^^y ■ ^ 

for all nodes. Sp, no, need to delete the txns from 

30 the io^. ^///''''J::'' .t'^''::':;:;:.^^;' \ - / 

Update " last l6g_EXTRACT riuniber for- Laptop in 
S_DpCK_STATUS 

Commit; , .... 

NumBatchTxns =0 
35 END IF; 

++NumTxns 

End Loop; /* Each transaction in the Txn Log table */ 

40 Commit . ^ 

Update last LOG_EXTRACt niimber for Laptop iii S_t)OCK_STATUS 
Commit; , . . . 



Close log file (if needed) 
45 IF UserTxnLogFileP ' •! NULL ' THEN 
Close File; 

END IF; ^:^.::i::X7,t^ J /i: 



50 



SJOI^ictApi 0; . - o vr. - - 

ClM*k VisibmtyRoutim^^ ^ ^ ^ 

- - ' Check if a^ precor^ the txn log is visible to a 
j laptopNoideld , . . v 

55 BOOL ' "ChieckVisibility (LaptopNodeld, LogRecordType, 
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Pr imaryRowId ) 

IF object is visible THEN 

Because CheckObjectVisibility {) also processes 

in^licit 

5 visibility events, -we must loop through ALL 

docking objects 

even if we already know that the Txn is visible. 
-- Exception: if the table has VIS_event_FLG = 'N' 
then we can return immediately. 
10 IF Table. visibilityEventFLG = 'N' THEN 

return TRUE; 
ELSE 

bVisible ="TOtJE/ ''' ' ' ' ' 

END IF; 

15 END IF; - — - 

END LOOP; 
END LOOP; - 

return bVisible; *^ • :a ? - ^ 

20 } •i:^!: 

. . - - - FCheck if an instance of 'a docking object is visible to 

the laptop user. 
25 Also processes implicit visibility events! 

BOOL V ChiarckOb j ectVisibil ity ( Lap t opNodeld , 

DockingObjectName, PrimaryRowId) 

FOR each visibility rule for the Docking Object LOOP 
30 IF RuleTypet» RuleSQL THEN -^^^ J' 

jjRun the select SQL statement%sing PrimaryRowId; 
IF any rows returned THEN-' " " 

u::.^^: r r Xi row is visible- • Y' - ' 

Process an implicit Download Object- 
35 DowntoadOb j ect Iris t ance { Lap t bpNodeld , 

PrimaryTableName/- or L : :>i -'xi: a-r :>r " 

■;(r:/:<:;.c:/:)':w>,i:: <rTc; •:*'>:'TrimaLripidwId) ; 
return TRUE;:o i.: -.r. J/r, --Mf. 
END ^IFrv* . LV"-?:'M: : -f.:: nxo: 



40 ELSIF RuleType » CheckDockingObject THEN 

Run the ParameterSQL*^''usiiig ^^-PrimaryRowId to get 
newPrimaryRowId 

> .'li mo'x': FOR each record ret rieved^'l^^^^ LOOP 

RECURSIVE! ' 
45.;.^ P jEa^v.: CheckObj ectVifi^^ • (La^t bpNodeld , 

CheckDockingObj ectName , r -ini^ ; ' 

e:ine^i}\^jcr:Ki s^d:, ::0IP^'. iv .*•. • newPrimaryRowId) f^^"'* 
IF rc = TRUE THEN 
'.uo - r r Process an iiriplicit *Dbwn^^^ 

50 D o w n 1 o a d O b j e c 1 1 n s t a n c e ( 'ii ap top N o d e I d , 

Pr imaryTableNaine , 

rui.e c ' s : . , '■'^ Prii^^ 

return TRUE; : . . » . 

^ a i: .* .-J^v:!:. -END -IF;- - . . ..ir..j.e,> r.-o 

55 END LOOP; 
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Struct 
{ 

CHAR* selectList; 
CHAR* fromClause; 
CHAR* whereClause; 

UINT numTables; /* also the nimber of joint to reach the 
Primary Table */ 
} GenStmt; 



10 



15 



20 



GeneratePrimaryldSQL (Table, DockingObject) 
{ • ■ • ~ 

/* there may be more than one SQL statement, so we have 
a dynamic _ ^ * 

array o£ SQL statements. Each element in the array is 
a path '[ 

from the Table to the Primary Table*/ 
DynArrld GehstmtAri:; , . ' /--^-i 
GenStmt newGenStmt;' ■ 

CHAR* sqlStnitr^^" ' ' " '-^ i iv ^ ?; : 

DynArrCreate (SinS.tipl^i:) 

25 Create the*^f irst; el^meiittJ^^ initialize 

hewGenStmt^;=i^inallp^ " VV , 

nevKSehStiht^mlinTabies ="^1;^^^ 
newGenStmt. selectList = "SELECT row_id"; 
newGenStmt . f i'omClause i "FROM ,;<Table> ^ tl " ; ; r. 

newGenStmt . wheregiau^e ^ = ViWHERE 1 1 . ROW_ID = : row^i'd" ; 
DyhArrAppend-- ^ ( GenS t nit Arr / 'i^ewGenS tijiit ) ; 

/* Recursively follow FKs tp .the Pr^^ */ 

Build the select:V fi'bm and wher^^ simultaneously 

AddPKTable (Table, DockingObject, ,GenStmtArr, 0) ; 

Union all the ^ paths . together ^ /:! . . .V: ' 

numStmts = DynArrSi¥e:.(Gdi^^^^ u 

•40 FOR all elenients'ln the' array 

tmpSqlStmt,. GenS'tmt Ar r [ j ] . selectList | j 

GenStmtArr[j] .fromClaiiir M,;?: ^ .\ 
. GenStmtArf[jl4i^fiificiaiise^^^ ^ 

sqlStmt' == sql^Sfmt ' I 1^ tmpSqlStmt; 
45 END LOOP; . . . ' 

DynArrDestroy (GenStmtArirf ; '''"^ * ' - " 



30 



35 */ 



'-iF:tsqistmt-4^SroL^^^^ ^ / : 

50 Error: nb'^atfi-^fcrom 'fable Co Primary table. 

END IF: 

) '---^ 

: » ''.,.'5" ■ . 

55 Recursively follow all FKs to the Primary Table 



0*' 
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Only count FKs to other member tables in the saune 
Docking Object 
++numFKs; 

5 END IF; 

END. LOOP; 

RETURN; 

} 

10 Process Visibility Events 

Download an Object Instance to a Laptop 
This function also downloads all Related Docking Object 
instances. . ^ r .(...v- 
15 BOOL DownloadObjectlnstance . (LaptopNodeld, ObjectName, 
. .. PrimaryRowId) . . , „ >• 

Check if the object instance is already downloaded to 
the laptop f; ,v . V >j_ : . v. 

20 Find the object ins tance^.dn the r-S^DOB J_INST table 
IF exists on laptop THEN; . -m^' • v. 

Vetum TRUE; ' . v 

END IF; . , : 1 i? 

25 - - Register ob j ect instance in S_DOBJ^INST table 

Write Download Object records to .the ,Txn. Log 
FOR each member table; of- the ...doicking' object LOOP 
Generate .;SQL. select,-;Sta^ download records 

30 . Write each retrieved record to the User Txn Log file 

END LOOP; ; rh,v. w ; ^• 

— Download records for Parent Object instances 
FOR each RelatedDockingObject LOOP i I'f. 
35 Run ParameterSQL to get r " newPrimaryld of 

RelatedDockingOb j ects 

FOR each newPrimaryld retrieved LOOP 

Check if the instance of the object is visible to 
the laptop user 

40 CheckObjectVisibility (LaptopNodeld, ObjectName, 

PrimaryRowId ) 

IF visible THEN 
DownloadObj ect Instance (LaptopNodeld, 

RelatedDockingOb j ect , 

45 newPrimaryRowId) ; 

END IF; 
END LOOP; 
END LOOP; 

50 return TRUE; 

} 



-- Remove an Object Instance to a Laptop 
35 -- This function also ranoves all Related Docking Object 
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We claim: 

1. A method of collecting, storing, and retrieving data 
in a database management system having a master 
5 database server (4), at least one workgroup server 

(315), and a plurality of workgroup user clients 
(310) V said workgroup server (315) interposed between 
said master database s^irv^r (4) an^'^said workgroup 
user clients (310) cdiiqprisirigf : 
10 - (a)* creating a trsinsactibn and a transaction file 

corresponding ^theire to ' iii one of said workgroup 
user clients (310) ; and 
(b) updating said transaction file into a database 
- - ■ • resident on said workgroup server (315) . 

15 ' =■ ■ - 

-2. The methbd "Of claim 1 cdmprisi'iig: 

(a) creating ^a transaction' in a "local database 
= , N •resident' on one of '^aid'*^' workgroup user clients 
(310), * 'entering' "" th*e ' 'transaction into a 
20 transaction log resident on said workgroup user 

client (310) , and creating a transaction file 
corf espoiSding thereto in an ""'outboac of said 
workgroup user client M 310 ) 

25 (b)" copying said* "^trein^actioh file to an inbox 

• < id¥htifi^d^to the 'wdrk^ user client (310) and 
'UEkiating said ' transact ioiS into a workgroup 
database (305)' resident on said workgroup server 
(315) , said workgroup database (305) including a 
30 -•transact i^ ^' ^'^'^ 

i' (c) ' reading ^aid workgrSup ^tabase (305) transaction 

' log, skipping 'ttio^e^'transact which originate 

at^3''^the -master dat (4), creating 

35 datS^a files corresponding t the entries therein, 

^ '^cojoying data files corresponding to trcuisactions 

originating at^the -workgroup user client (310) to 
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and updating the transactions into a master 
database (3) on the master database server (4) • 

6. The method of claim 4 comprising: 

5 (a) copying said transaction file to an inbox 

identified to the workgroup user client (310) and 
updating said transaction file into a workgroup 

database (305) resident on said workgroup server 

(315), said workgroup database (305) including a 
0 transaction log; arid 

(b) reading said workgroup database (305) transaction 
log/ skipping those transactions which originate 
at the master database server (4) , creating data 
5 files ' corresponding to the entries therein, 

' copying data files corresponding to trsinsactions 
ofxginatihg at the workgroup user client (310) to 
dn*' inbox"^ on the master database server (4) 
' corresponding to the workgroup server (315), and 
0 ' updkting the transact Ions into a master database 

(3) on the master datcibase server (4). 

7. An' article of manufacture comprising a computer usable 
jmedium having computer rea^ program code means 

5 ^^'"'Wibbdied'' theirein for collecting, storing, and 

reprieving data in a database management system having 
a master datcibase server (4) , at least one workgroup 
server (315) , and a plurality of workgroup user 
' clients (310), said workgroup server (315) interposed 

0 • ' '"'between' said master ' database server (4) and said 
-'Workgroup user clients (310), the computer readable 
"-'"^program means in said article of manufacture 
c6n5>rising: 

5 . • -(a) computer readable ' program code ineans for causing 
- a coraputef to effect creating a transaction in 
a local database resident on one of said 
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Steps comprising: 

(a) creating a transaction in a local database 
resident on one - of said workgroup user clients 

5 (310) , entering the transaction into a 

transaction log resident on said workgroup user 
client (310), , and creating a transaction file 
corresjponding tKef eto"^^ in an outfiox 'of said 
" workgroup user client i(3l0) ; ' * i 

(b) • copying said .transaction file I to aii inbox 



' - ' identified to tKeljIwoffcgroup user client (310) and 

updating said transaction! file^ into a workgroup 
database (305) resident on said 'workgroup server 
L^, .. !t315).,„^,,said workgroup database (305) including 

a transkction log; and 

' (c) reading said 'workgroup databa^se (305) transaction 

X ^ ^- - t 

log , skippirig;7*; those :transactiidns which 

h \20 : : 1 originate at " 'the:|-iiiast:^err4dktabase { server (4) , 

I . \ - . . ^ . . 5 m^iiL W i \ \ : ' 

^ ^ creating data J- " files 'corresponding to the 

I . entries therein, copying data files 

I 7. ; f corresponding to transactions -^originating at the 

{ ^ .. i workigroup user client (310) to an inbox on the 

] ' ' - . • I 

25 ; --i mas tet "database server (4) corresponding to the 

f 

workgroup server (315) , and updating the 
transactions into a master datcQsase (3) on the 
master database server (4) . 



CO 



7 



-45- 



BNSDOCID: <WO__9838564Aa.l_> 



I 

wo 98/38564 



I 

PCTAJS98/037S2 



2/10 



r 



63 



S_DOBJJNST }—z 



T 



^65 



■67 



NODE 



S REL DOBJ 



T — r 



^61 



-S_DOBJ 



PRIMARY 
TABLE - 



SzDOBJ^VIS.RULE 



\ ■ 



^69 



S_DOBJ_TBL 



^73 



S APP TBL 



COLUMN i 
GROUP " 



A. 



87 



FOREIGN KEY- COLUMN 



A. 



USER KEY COLUMN 



^75 



- S APP COL 



P4 



BNSOOaD: <WO SB3asS4A2 I > 



SUBSTrrUtE SHEET (RULE 26) 



wo 98/38564 



PCT/US98/03752 



4/10 



START 



121 



25 








;> CONNECT TO 
. 'CENTRAL 
COMPUTER 


•• or. J 


r 



723 




"•^i ''' '' 



F/G-4 



BNSOOCIO: <WO_98385e4A?.l_> 



' ^ sil^sHttUTE SHEET (RULE 26) 



PCTAJS98/03752 




: FIND 1 
UNPRO( 
TRANSi 


FIRST 
3ESSED 
atCTION J 


1 




SELECT 
TRANSACTION . 



175 




YES 



CALbVISIBILITY 
CALCULATOR 




X. ' 


YES 

' - -r 


-rss 


WRITE PARTIAL 
TRANSACTION 
L0(3 








UPDATE L/CST-' 
LOG- 
EXTRACTED 





9 



1 ear- ^•>'^-"' 

■ I,. . ... •• 




189 



UPDATE; LAST- 
LOG- 
EXTRAbTED 



191 



,_6 



■^'^ SUBSmUTE SHEETIMlE 26) 



wo 98/38564 



I 



\ 



PCTAJS98/03752 



8/10 




BNSDOCID: <W0u_8838564Aa.L> 



•SUBSTITUTE i5HEET (RUtE 26) 



i 

W098A38564 PCTAJS98/037S2 



10/10 



^360 

NODE 
RELATIONSHIP 



370 



DOCK OBJECT INSTANCE )--- 



I I 

I I C— 



NODE 



350 



375 



DOCK STATUS 



F/G- 10 



L ^365 



■380 



NODE 
EMPLOYEES 



EMPLOYEES 



BNSOaCID: <WO_9838564A^I_> 



SUBSTITUTE SHEET (RULE 26) 



WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 




PCX 

INTERNATIONAL APPUCATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) Internalional Patent Classification ^ : 
G06F 17/30 



A3 



(11) InternaUonal PublkaUon Number: WO 98/38564 

(43) International Publication Date: 3 September 1998 (03.09.98) 



(21) International Application Number: PCrr/US98/03752 

(22) International Filing Date: 24 February 1998 (24.02.98) 



(30) Priority Data: 
60/039.230 



28 February 1997 (28.02.97) US 



(71) Applicant (for all designated States except US): SIEBEL 

SYSTEMS. INC. [USAJS]; 1855 South Grant Street. San 
Mateo. CA 94402 (US). 

(72) Inventors; and 

(75) Inventors/Applicants (for US only): BRODERSEN, Robert. 
S. [US/US] ; 17 S pinaker Drive, Redwood City. CA 94065 
(US). CHATTERJEE. Prashant [US/US); 21281 Glenmont 
Drive. Saratoga. CA 95070 (US). LIM, Peter. S. [US/US]; 
917 Governors Bay Drive. Redwood City. CA 94065 (US). 

(74) Agents: GOLDMAN. Richard, M.; Cooley Godward LLP. Five 
Palo Alto Square. 3000 EI Camino Real, Palo Alto, CA 
94306-2155 (US) et al. 



(81) Designated States: AL. AM, AT. AU. AZ. BA. BB, BG, BR, 
BY. CA. CH. CN. CU. CZ. DE. DK. EE, ES, FI, GB, GE. 
GH. GM. GW. HU. ID. IL. IS. JP, KE. KG. KP, KR. KZ. 
LC. LK. LR. LS. LT. LU, LV. MD. MG, MK, MN, MW. 
MX, NO, NZ, PL. PT. RO. RU, SD. SE. SG. SI. SK. SL. 
TJ, TM. TO. rr, UA. UG. US. UZ. VN. YU. ZW, ARIPO 
patent (GH, GM. KE. LS. MW. SD, SZ, UG. ZW). Eurasian 
patent (AM. AZ, BY. KG, KZ, MD, RU. TJ, TM), European 
patent (AT. BE, CH. DE, DK. ES. FI. FR. GB. GR. IE. IT, 
LU. MC, NL. PT. SE). OAPI patent (BF, BJ. CF, CXi. CI, 
CM. OA. GN. ML. MR. NE. SN. TD. TG). 



Published 

With international search report. 

(88) Date of pnblicatioD of the intemationa] search report: 

29 October 1998 (29.10.98) 



(54) Title: PARTIALLY REPLICATISD DISTRIBUTED DATABASE WITH MULTIPLE LEVELS OF REMOTE CLIENTS 
(57) Abstract 

A method of and system for collecting, storing, and retrieving data in a database management system. The database management 
system includes a. master database server (4), at least onc.worisgroup server (315), and a plurality of workgroup user clients (310).„Thc 
workgroup server (315) is interposed between the master database server (4) and said workgroup user clients (310). The method creating a 
transaction in a local database resident on one of the workgroup user clients (310), entering the transaction into a transaction log resident on 
the workgroup user client (310), and creating a transaction file corresponding to the transaction in an oulbox of said workgroup user client 
(310), Next, the transaction file is copied to an inbpx identified to the workgroup user client (310) and updating the transaction file into a 
workgroup database (305) resident on the workgroup server (315). The workgroup database (305) includes a transaction log. 



BhlSDCX;!I>: <WQ_9e38S64A3J_> 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/US98/03752 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC(6) :006r: 17/30 

US CI. :707/L 10. 100. lOL !03 
According to International Patent Classification (IPC) or to both national classification and IPC 



FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 
U.S. : 707/1, 10. too. 101. 103 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 
none 



Electronic data base consulted during the international search (name of data base and. where practicable, search terms used) 
APS 

workgroups, groupware. middleware, shareware, database distribuUon, file accessing, transaction management, logging 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category* 



Citation of documenu with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



X,E 

Y,P 
A. E 



US 5,764,899 A (EGGLESTON et al.) 09 June 1998 (09.06.98), 
abstract, lines M6, fig. 1, items 110 & llSfig. 2, items 201-215 & 
226-264. 

US 5,765,038 A (FLANNERY et al.) 09 June 1998 (09.06.98). col, 

9, claim 1, lines 25-64, col. 10, claims 2-8, & lines 1-62. 

US 5,664,183 A (CIRULLI et al.) 02 September 1997 (02.09.97), 
abstract, lines 1-10, col. 9, claim 1, lines 23-42, col. 9, claims 9 & 

10, lines 6-65, & col. 11, claim 13, lines 7-38. 

US 5,745,897 A (PERKINS et al.) 28 April 1998 (28.04.98), 
abstract, lines 1-19. 



1-6 

7-8 
1-8 

1-8 



"xl Further documents are listed in the continuation of Box C, []] See patent family annex. 



special calegoriei of cited documents: 

document definii^ the general state of the art which m not considered 
to be of particubr relevance 

earlier document published on or after the international filing dale 

document which may throw doubts on priority clatm(s) or which b 
cited to establish the publication date of another citation or other 
special reason (as specified) 

document referring to an oral disclosure, use. exhibition or other 



document published prior to the tniernauonal filing dale but later than 
the priority date claimed 



later document published after the iniernationat filing date or priority 
date and not in condici with the application but cited to understand 
the principle or theory underlytiig the invention 

document of particular relevance; the claimed inveiuion cannot be 
considered novel or cannot be considered to involve an inventive step 
when the document is taken aione 

document of paiticular relevance; the claimed invention cannot be 
considered to involve an inventive step when the document b 
combined with one or more other such documents, such c 
being obvious to a person skilled in the art 

document member of the same patent family 



Date of the actual completion of the international search 



23 JUNE 1998 



Date of mailing of the international search report 



2 1 m m 



Name and mailing address of the ISA/US 
Commissioner of Patents and Trademarks 
Box PCT 

Washington, D.C. 20231 
Facsimile No. (703) 305-3230 



Authorized officer 



CHERYL LEWIS ^TYllt^ 



Telephone No. (703) 305-8750 



Form PCT/ISA/210 (second sheetXJuly 1992)* 

BNS130CID: <WO_98385a4A3J_> 



